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REMARKS 

Applicants respectfully request favorable reconsideration of this application, as amended. 

Applicants note with appreciation that (1) the drawings have been accepted, (2) the 
claim for foreign priority under 35 U.S.C. § 119 has been acknowledged and certified copies of 
the priority documents have been received, and (3) the information disclosure statements filed 
on October 16, 2006, May 31, 2007, October 22, 2007 and June 26, 2008, have been 
considered. See, Office Action Summary (Page 1). 

Claims 1, 2 and 5 were rejected under 35 U.S.C. § 112, 2"'' paragraph, as being 
indefinite. In response, these claims have been amended, as necessary, to correct 
antecedence, as suggested by the Office Action (Page 3). No new matter has been added, and 
Applicants respectfully submit that the indefiniteness rejections have been overcome. 

Claims 1, 2, 5 and 6 were rejected under 35 U.S.C. § 103(a) as being unpatentable over 
3GPP-TS 29.060 v3.7.0 (2000-12) (hereinafter "3GPP 1999"), while claims 3, 4, 7 and 8 were 
rejected as being unpatentable over 3GPP in view of 3GPP-TS 09.60 v6.10.1 (hereinafter 
"3GPP 1997"). Applicants respectfully traverse the merits of the rejections. 

In the interests of securing an expedited Notice of Allowance, and without acceding to 
the rejections. Claim 1 has been amended to incorporate the features recited by Claim 4, which 
has been canceled. Additionally, the Specification has been amended to comport with Claim 1. 
Claims 3, 7 and 8 have been canceled without prejudice, and Applicants reserve the right to 
pursue the subject matter recited by these claims in one or more continuation applications. 
No new matter has been added. Applicants respectfully submit that none of the cited 
references, taken either singly or in combination, teaches or suggests these features. 

Applicants respectfully submit that at least the following features distinguish Claim 1 
over the cited references: 

2D) if the processing result is that the GSN fails to create a PDP context 

because no free dynamic PDP address is available, reading the Create PDP 
Context Request message and checking the version number of the message 
according to a message header thereof, if it is the GTPvl version, the Cause 
value is set as "All dynamic PDP addresses are occupied"; othenA/ise, it is the 
GTPvO version, and the Cause value is set as "No resources available"; 



Page 5 of 8 



Serial No.: 10/568,270 



Att'y Dkt: 56815.1400 



2E) if the processing result is that the GSN fails to create a PDP context 
because there is no enough memory available, reading the Create PDP Context 
Request message and checking the version number of the message according to 
the message header thereof, if it is the GTPvl version, the Cause value is set as 
"No memory is available"; otherwise, it is the GTPvO version, and the Cause 
value is set as "No resources available". 

In view of the above different features. Applicants submit that, only in the case of "the 
processing result is that the GSN fails to create a PDP context because no free dynamic PDP 
address is available" or "the GSN fails to create a PDP context because there is no enough 
memory available", the step of checking the version number of the message is needed. 

Comparatively, in the cited document 3GPP 1999, the message is sent from a GGSN 
node to a SGSN node in response to a Create PDP Context Request. When the SGSN receives a 
Create PDP Context Response with the Cause value indicating 'Request Accepted,' the SGSN 
activates the PDP context and may start to fonward T-PDUs to/from the MS from/to the external 
data network. The Cause value indicates whether a PDP context has been created in the GGSN. 
A PDP context has not been created in the GGSN if the Cause differs from 'Request accepted.' 
The version field is used to determine the version of the GTP protocol. If a receiving node 
receives a GTP control plane message of an unsupported version, that node returns a GTP 
Version Not Supported message indicating, in the Version field of the GTP header, the latest 
GTP version that that node supports. The received G-PDU is then discarded. A GTP "version '0' 
only" GSN may not be listening on port 2123 and, as such, the GTP will not be able to send 
back a Version Not Supported message to a peer trying to establish a dialogue using GTP-C. As 
such, a GSN supporting both version '1' and version '0' shall fall back to version '0' if the 
attempt to contact a peer using version '1' fails. See, e.g., P19, Section 7.3.2, lines 1-26; P12, 
Section 6 - GTP Header, lines 12-16; and P76, Section 11.1.1, lines 5-6. 

Applicants submit that 3GPP 1999 simply does not disclose the claimed feature "if the 
processing result is that the GSN fails to create a PDP context because no free dynamic PDP 
address is available, reading the Create PDP Context Request message and checking the version 
number of the message according to a message header thereof." 
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The Office Action opines that P12, Section 6 - GTP Header, lines 12-16, and P76, Section 

11.1.1, lines 5-6 in 3GPP 1999 discloses "reading the Create PDP Context Request message and 
checking the version number of the message according to a message header thereof." 
However, as discussed above, 3GPP 1999 simply indicates that the "version field is used to 
determine the version of the GTP protocol," but it does not recite how or when to check. 
Specifically, 3GPP 1999 does not disclose "if the processing result is that the GSN fails to create 
a PDP context because no free dynamic PDP address is available, reading the Create PDP 
Context Request message and checking the version number of the message according to a 
message header thereof." In other words, 3GPP 1999 does not teach (or even suggest) that 
"checking the version number of the message according to a message header" is performed in 
the case that "the processing result is that the GSN fails to create a PDP context because no 
free dvnamic PDP address is available." 

Further, although 3GPP 1999 indicates the Cause value of "All dynamic PDP addresses 
are occupied", it fails to disclose how to use the Cause value, i.e., e.g., it does not indicate that 

the Cause value is set as "All dynamic PDP addresses are occupied" if the processing result is 
that the GSN fails to create a PDP context because no free dynamic PDP address is available 
and that it is determined that the version is the GTPvl version. Similarly, 3GPP 1999 does not 
disclose how to use the Cause value of "No resources available." 

Applicants respectfully submit that 3GPP 1999 does not disclose the claimed feature "if 
the processing result is that the GSN fails to create a PDP context because no free dynamic PDP 
address is available, reading the Create PDP Context Request message and checking the version 
number of the message according to a message header thereof, if it is the GTPvl version, the 
Cause value is set as 'All dynamic PDP addresses are occupied;' otherwise, it is the GTPvO 
version, and the Cause value is set as 'No resources available'." 

Similarly, 3GPP 1999 does not disclose the claimed feature "if the processing result is 
that the GSN fails to create a PDP context because there is no enough memory available, 
reading the Create PDP Context Request message and checking the version number of the 
message according to the message header thereof, if it is the GTPvl version, the Cause value is 
set as 'No memory is available;' otherwise, it is the GTPvO version, and the Cause value is set as 
'No resources available'." 

Applicants submit that 3GPP 1997 also fails to disclose these claimed features. 
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Moreover, Applicants respectfully submit that the claimed performing internal processing 
and getting a processing result before checking the version number, and checking the version 
number in some cases to implement compatibility of different protocol versions, can not be 
obviously derived from the cited references. Thus, when compared to the cited references, the 
claimed invention is more effective, i.e., e.g., because the GSN would not need to check the 
version number of the message in all cases. 

Consequently, Claim 1 is allowable over 3GPP 1999 and 3GPP 1997. Moreover, none of 

the remaining references cure their deficiencies. 

Furthermore, Claims 2, 5 and 6, depending from Claim 1, are also allowable, at least for 
the reasons discussed above. Applicants also submit that the cited references fail to teach or 
suggest many of the features recited by the dependent claims, and, consequently, that these 
claims are independently allowable. 

In view of the foregoing amendments and remarks, Applicants respectfully submit that 
this application is in condition for allowance and should now be passed to issue. 

A Notice of Allowance is respectfully solicited. 

If any extension of time is required in connection with the filing of this paper and has 
not been requested separately, such extension is hereby requested. 

The Commissioner is hereby authorized to charge any fees and to credit any 
overpayments that may be required by this paper under 37 C.F.R. §§ 1.16 and 1.17 to Deposit 
Account No. 50-2036. 



Respectfully submitted. 
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